x86/hvm: don't unconditionally create a default ioreq server

x86/hvm: don't unconditionally create a default ioreq server

Avoid doing so if the domain is not under construction.

If upstream QEMU is in use then it will explicitly create an ioreq server
rather than implicitly creating the default ioreq server, which is a
side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN,
or HVM_PARAM_BUFIOREQ_EVTCHN (as is done by legacy QEMUs).

However, if the domain is subsequently saved/migrated then those parameters
are read and hence the default server will be unnecessarily instantiated.

This patch adds an extra check of the 'creation_finished' flag when those
HVM params are read and will only instantiate the server if the domain is
under construction, which will always be the case when QEMU is invoked.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/hvm: Fix HVMOP_get_param when skipping creating the default ioreq server

c/s e7dabe5 "x86/hvm: don't unconditionally create a default ioreq server"
added a break statement, but the logic previously depended on falling through
into the default case to fill in the value the caller asked for.

This causes the sending migration code to put a junk PARAM into the stream,
and the receiving side to fail to zero the IOREQ pages, causing QEMU to object
when it finds stale requests while starting up.

Reorder the code so it more clearly falls through into the default case.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
master commit: e7dabe59c3239dc9ef9edbc49ed54f754616ebf7
master date: 2016-12-12 09:49:10 +0100
master commit: 451c9938c68ccb77ff94765f7ac47e8de51d3f43
master date: 2016-12-13 09:58:33 +0000